剛接收到「新增會員上傳大頭貼」新需求的你，以最高效率找了團隊的工程師們一起討論時程：「這個功能，大家覺得大概需要多少時間呢？」

團隊內最資深的工程師阿麥滑動了一下設計稿，胸有成竹地說：「喔，這個我看過，就是一個上傳元件嘛，很單純。後端 API 也有現成，大概 3 天吧？」

你看著阿麥那自信的眼神，又看了看團隊中其他比較資淺的工程師，希望他們給予其他的觀點但遲遲沒有下文，於是心想：「阿麥都說 3 天了，那應該就是 3 天吧。」你爽快地在專案管理工具上，為這個任務標上了「 3 天」的估期。

然而，當團隊實際開始動工後，就發現原來代誌不是憨人想的那麼簡單：

• 使用者上傳的圖片，需要做裁切、壓縮，還要做頭像的圓形預覽。
• 後端的 API 雖然有，但缺乏處理大尺寸圖片的保護機制，一上傳就超時。
• 還有需要處理圖片上傳失敗、格式不符、甚至是有心人士上傳惡意檔案的各種例外狀況。

那個從阿麥口中輕鬆寫意說出的 3 天承諾，就如同渣男的蜜糖毒藥，直接在現實面前無情戳破，最終演變成一場長達兩週、充斥著加班、爭吵與道歉的噩夢。

症狀診斷

當你陷入這種狀況的時候，在此宣佈你確診為「估算樂觀偏誤症」

在繼續往下看之前，我們先釐清一下它與前一個病症的兄弟關係：

• 病症 07 是你根本不知道冰山的全貌，病因是「範疇不清」。
• 今天的 病症 08 則是你已經看到了冰山，卻天真地以為自己開的是一台破冰船，能三天就把它撞開，病因是「時程誤判」。

這個病的根源，在於我們的大腦天生就有「樂觀偏誤」。在壓力下，我們會下意識地忽略所有潛在的風險，只考慮最順利的「理想路徑」，然後給出一個聽起來很棒，但幾乎不可能達成的時程承諾。

新手 PM 往往把工程師的「直覺猜測」奉為「神聖誓言」；而資深 PM 則像專業氣象預報員，不會斬釘截鐵地說「明天一定出太陽」，而是說「明天降雨機率是 20%」。

作為專案經理，你的職責不能武斷地給出單一期限，而是必須要基於經驗和數據，在心裡找出一個合理的「時間可能性區間」。

處方籤

這份處方除了方法，更多會著重在跟團員的對話、溝通，而在我們開始學習如何「提問」之前，有一件更重要的事：你的提問品質，取決於你對「複雜度」的敏感度。

而這個敏感度，正是我們在病症07的處方籤中所鍛鍊的（點我回去鍛鍊）。你越是熟練地在平時用那四把手術刀（使用者旅程、正反向流程、角色權限、跨功能依賴）去拆解各種功能，你的大腦中就越會建立起一張風險地圖。

當你聽到「上傳大頭貼」時，你的腦中就會自動浮現「圖片壓縮」、「權限管理」、「CDN流量」等關鍵字。有了這張地圖，你的提問才會精準、有力，才能真正引導團隊看見冰山的全貌。所以，請務必將病症 07 的處方，當作你日常的內功來修煉。

第一步：先學會「三點估算法」這個工具

針對任何一個任務，你心中都應該要有三個數字，而不是一個：

• O - 樂觀時程
  「如果宇宙大發慈悲，沒有任何會議打擾，需求清晰無誤，一次就寫對所有程式碼，需要多久？」
• M - 最可能時程
  「憑我們的經驗，正常情況下，考慮到一些小問題和日常雜務，大概需要多久？」
• P - 悲觀時程
  「如果墨菲定律顯靈，API 文件是錯的、關鍵人生病、需求方突然失憶，最慘最慘會需要多久？」

第二步：用「引導式提問」引出團隊的三點估算

有了上面的三點概念後，下一步就是如何引導團隊使用。

面對像阿麥一樣對自己自信的工程師，直接要求他用三點估算法，高度可能會被認為是不信任他的專業，輕則態度不屑重則對你惡言相向，所以面對這種型態的工程師，你需要更有技巧地去引導。

當工程師說：「這個大概 X 天吧。」 → 我們先把這個時程天數，當作 M 最可能時程

• 悲觀情境建議的通用提問句型：
  「了解，X 天聽起來很不錯。那想跟你請教一下，如果我們要考慮到最壞的情況，例如 [舉一個相關的潛在風險，例如：第三方 API 不穩定]，你覺得最慘可能會需要多久的時間來除錯？」
• 樂觀情境建議的通用提問句型：
  「反過來說，如果一切都超順利，完全沒有任何意外，有沒有可能比 X 天更早搞定？」

透過這種方式，引導他一起思考得更周全，而你也會獲取到你所想知道的三點時間點。

第三步：建立你自己的「私房估算日誌」

在你一開始對任何功能的評估沒有任何經驗、概念的時候，我會十分建議一定要進行這個步驟。

請準備一個只有你看得到的試算表，記錄下每一次的估算與實際結果，以下的表格範例可以參考：

第四步：在複盤會議中「向前看」，而非「向後看」

在複盤會議中，絕對不要拿出你的日誌說：「你看！阿麥你上次估三天，結果做了七天！」這是在製造敵人，並且你的未來溝通之路會更坎坷，你的目標是引導團隊從過去的經驗中學習，應用到未來。

• 錯誤的問法： 「我們上次為什麼估錯了？」 這樣的問法充滿著究責語氣。
• 建議的通用提問句型：
  • 「夥伴們，我們上個 Sprint 在處理 [某個類型的任務，例如：第三方串接] 時，學到了一些寶貴的經驗。這個 Sprint 我們有一個類似的 [新任務名稱]，有了上次的經驗，我們這次在估算上，有沒有需要特別考慮進去的地方？」
  • 「上個 Sprint 中，哪個任務的估算和實際狀況最接近？我們當時是怎麼估的？這個成功經驗可以複製到這次的其他任務上嗎？」

不用刻意提「估算準不準」，因為認真來說本來就不可能每次都預估到很準，更重要是引導團隊將「已知的教訓」，應用到未來的任務上，那麼不僅估算的落差幅度會越小，而團隊也會跟著你一起在評估思考上越來越全面。

臨床實戰

好，現在讓我們回到開頭那個讓 PM 胃痛的「上傳大頭貼」場景。當時，資深工程師阿麥憑直覺給了「三天」。如果我們當時沒有直接接受，而是啟動了我們的「私房筆記術」，情況會如何發展？

第一步：啟動引導式提問

你不會直接接受「三天」，而是會說：「好的，阿麥，三天是我們最可能的時程。那想跟你請教一下，如果我們要考慮到最壞的情況，例如後端 API 要大改、還要處理一些奇怪的圖片格式，你覺得最慘可能會需要多久？」

經過一番討論，你得到了三個數字：樂觀(O)=1.5天，最可能(M)=3天，悲觀(P)=10天。

第二步：在你的私房日誌中計算與記錄

你回到座位，打開你的秘密武器「估算日誌」，尋找過去相似度比較高的功能來做一個比較、估算，最後你得到一個 2 天到 10 天的估算範圍。

這時候相信你已經心裡有數，這個任務的風險區間很大，所以在對外溝通時，你是完全不能直接以阿麥的 3 天作為答案，會建議抓一個中間值比如 5 天作時程回報。

第三步：事後校準與學習

兩週後，這個功能實際花了 7 天才完成，比你自己預期的天數還是多了 2 天，那麼就要透過覆盤會議上跟大家了解這中間遇到的困難，不僅幫助你自己的日程筆記又可以多更多補充，也帶著團隊一起思考，那麼這一次的估算落差，就會變成了你和團隊共同成長的養分。

特別門診：如何將估算範圍，轉化為可靠承諾

嘿，這次沒有 B 計畫。畢竟，估計時程區間需要靠反覆練習與累積經驗才能更加上手。不過，除了估計時程外，還有另一件重要事情：對外如何報時程。尤其當這個功能是上級或老闆特別關注的任務時，如何有效地報告時程評估就成為另一門溝通藝術，這正是特別門診想要補充的部分。

我們透過跟團隊獲取資訊和自己過去的經驗，總結得出了一個 2 - 10 天的估算範圍。但你知道，直接拿這個範圍去跟老闆報告，無異於自殺，因為我們報時程本來就不可能給一個區間。老闆要的不是可能性，而是確定性。

此刻，我們要化身為風險談判專家，將團隊內部的「科學分析」，轉化為對外部的「商業承諾」。那麼我們該怎麼跟老闆溝通，會既給老闆確定性，又能確保萬一的變化性呢？

你的溝通策略如下：

第一步：在你心中，選定一個「承諾數字」

基本上不建議你報 2 天（太樂觀了），也不要報 10 天（太悲觀了），通常會落在「最可能時程」和「悲觀時程」之間，在上面臨床實戰我們選擇「5 天」這個數字，這樣既包含了緩衝，也不會顯得團隊的工作企圖太低。

第二步：給出數字，但「綁定假設」

• 你可以先說： 「老闆，經過我們團隊的詳細評估，我們承諾可以在『 5 天』內完成。」在這邊直接給出你選定的單一數字。
• 接著，立刻綁定假設： 「這個 5 天的承諾，是基於幾個關鍵假設：第一，我們能在一日內拿到 API 文件；第二，協作窗口能即時回覆我們的問題。」
• 潛台詞： 我給了你想要的確定性，但這個確定性，是還有其他跨單位要共同維護。如果假設不成立，時程就需要重新討論。

第三步：提供「超標的可能性」

• 最後還要說： 「當然，如果這幾個假設都進行得非常順利，我們有機會在 5 天內提前完成，給客戶一個驚喜。」
• 潛台詞： 我是一個有野心的 PM，我承諾的是一個可靠的底線，但我們團隊會挑戰更高的目標。

最後的醫囑

所以，下次當有人問你「這個大概要多久？」時，請記住一個關鍵的區別：業餘者給出「猜測」，而專業者提出「預測」。

一個「猜測」是基於個人直覺的脆弱承諾，沒有意外之下都會在現實的衝擊下粉身碎骨。而一個「預測」則是基於團隊共識、風險分析與歷史數據的科學推論，既有彈性也經得起考驗。

每當迷之自信型態工程師又對我誇下海口時

直接當作遇到跳樓大拍賣可信度先砍個 50% off 卡特懂ㄛ